[Split 1/3] Restructure modules: java/android → core/core-android under io.ably.pubsub - #1232

So is the idea here that, if I'm using java on a server say, I now need two artifacts: io.ably.pubsub:server and io.ably.pubsub:core ?

So is the idea here that, if I'm using java on a server say, I now need two artifacts: io.ably.pubsub:server and io.ably.pubsub:core ?

afaict, you declare one dependency, io.ably.pubsub:server, and Maven/Gradle resolves io.ably.pubsub:core transitively

So is the idea here that, if I'm using java on a server say, I now need two artifacts: io.ably.pubsub:server and io.ably.pubsub:core ?

afaict, you declare one dependency, io.ably.pubsub:server, and Maven/Gradle resolves io.ably.pubsub:core transitively

That's true, but why is it necessary? What's the problem with having a single server artifact that contains the server and core java packages?

So is the idea here that, if I'm using java on a server say, I now need two artifacts: io.ably.pubsub:server and io.ably.pubsub:core ?

afaict, you declare one dependency, io.ably.pubsub:server, and Maven/Gradle resolves io.ably.pubsub:core transitively

That's true, but why is it necessary? What's the problem with having a single server artifact that contains the server and core java packages?

If I'm understanding correctly, you're suggesting we solely have just 2 packages - device and server, and each of these have "core" embedded in them.

There's a couple reasons having core live outside works better imo...

1. As answered above, transitive package handling means the end users don't need to know about core anyway
2. Other products that build on a pubsub realtime client e.g. Chat, can work with either the device or server pubsub package, but they need a shared understanding of what that realtime interface is. The core split keeps that shared understanding between them. Another solution would be that Chat itself declares the interface it needs, but this gets into the realms of type erasure and inverting how this model works today.
3. There are packages that should be neutral e.g. LiveObjects. We currently just pass in a LiveObjects plugin without needing to declare device or server (hence the DR's decision of it being okay for internal dependencies to rely on core). If we bundled Core into the device and server packages, LiveObjects would need to identify as one or the other which breaks the mental model for how it works

I've been speaking with @AndyTWF about this too, so happy for us 3 to jump on a call if we need to

Walkthrough

The project now uses core and core-android instead of java and android. Publishing coordinates, dependent modules, CI workflows, contributor commands, and documentation were updated accordingly. The Maven version is now 2.0.0.

Changes

Core module transition

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Refactor

Suggested reviewers: ttypic

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{A rabbit reads each line,
The patch grows clear beneath the moon,
Small changes hop in place,
Tests guard the garden path,
Reviews bloom before the dawn.}

_{Comment @coderabbitai help to get the list of available commands.}